平台工具[2]架构设计02.微服务架构

SOA, 架构设计

2024-01-27

微服务架构概述

Catalogue

词条：可维护性、可扩展性、可重用性；复杂性、耦合度；独立开发、部署和升级；灵活、可重用和可扩展、架构方法；系统复杂度、系统性能、部署和运维、服务依赖、服务管理/治理、系统稳定性和可用性；专注于业务逻辑、底层的基础设施和资源管理

本文主要从三个方面(微服务架构发展史、系统架构设计原则、微服务架构相关技术)介绍微服务架构的相关概念和方法.

1.架构模式的发展历程

单体架构
分布式计算
SOA架构(面向服务)[20世纪90年代]
微服务架构时代
后微服务时代

1.1 单体架构

整个应用程序作为一个单元进行开发、部署和运行的架构模式。主要特点是：一体化、技术单一、紧耦合、部署简单。
优点是：开发简单、测试相对容易；缺点：扩展困难、维护复杂、技术升级困难、容错性低。
单体架构适用于规模较小、业务逻辑相对简单的应用，当业务发展到一定的规模后，需要向更灵活的架构演进。
软件设计经常使用经典的3层模型，即表现层、业务逻辑层和数据访问层。

1.2 分布式计算

发展背景：

计算能力的需求增长：网络产生的数据量的增加、
互联网技术的发展：通过互联网，可以将计算任务分配给世界各地的计算机进行处理，从而充分利用了全球范围内的计算资源。这种“蚂蚁搬山”的方式将具有很强的数据处理能力。

现在，分布式计算已经被用于各种领域，如科学研究、数据分析、云计算等。基于云计算的分布式计算、基于大数据的分布式计算。

1.3 SOA架构

相比单体架构，更灵活的架构模式是什么样的呢? 面向服务的架构:SOA架构

SOA的架构出现，提出一种面向服务的架构模式，将应用程序的不同功能单元独立成服务。服务之间通过网络通信。
SOA的主要目的是提高软件系统的灵活性、可复用性和扩展性。以更好的应对业务的变化和发展。强调服务的组合和重用，而不是紧密耦合的大型单体应用。主要目标是实现跨平台的、可重用的服务，以支持复杂的企业级应用

SOA粗暴理解：把系统按照实际业务，拆分成刚刚好大小的、合适的、独立部署的模块，每个模块之间相互独立。

而SOAP、REST、RPC就是为了实践这种设计模式而设计的数据通讯方式，其中SOAP通俗理解就是服务间通过http+xml的形式完成数据交换，REST就是http+json的形式，RPC是基于socket的形式。CXF框架就是典型的SOAP.

1.3.1 发展背景

(20世纪90年代)源于企业对于提高软件系统灵活性、可扩展性和可维护性的需求。
随着企业业务的快速发展和市场竞争的加剧，企业对于软件系统的要求也越来越高。传统的单体架构由于其紧密耦合、低可重用性和低可扩展性等问题，已经无法满足企业的需求。企业需要一种更加灵活、可重用和可扩展的架构方法，以支持其业务的快速变化和技术的不断更新。

SOA提供了一种新的设计和实现大型企业系统的方法。通过将应用划分为松耦合的服务，每个服务执行特定的业务功能，SOA架构使得系统更加灵活、易于扩展和维护。

使得企业可以更加快速地响应市场变化和业务需求，提高了企业的竞争力和市场地位。

1.3.2 特点

相较于单体架构：更加灵活、可重用和可扩展的架构方法
松耦合的服务
系统更加灵活、易于扩展和维护
自治性：服务可以独立开发、测试、部署和管理

1.3.3 不足

SOA架构的实现和管理复杂度也相对较高

系统复杂度较高：涉及多个服务之间的协作和通信(开发、测试和维护的成本相对较高、增加出错的几率)

性能问题：服务之间的通信的网络延迟和性能损失

安全性难以保障：需要对数据传输进行加密和安全控制，以保障系统的安全性

部署和运维难度大：涉及多个服务的部署和管理，增加了系统的复杂性和运维成本

服务之间的依赖性：服务之间的依赖关系可能比较复杂，一个服务出现问题或升级，可能会影响其他与之相关的服务。因此，需要仔细设计和管理服务之间的依赖关系，以确保系统的稳定性和可用性。

当然服务拆分之后也存在一些问题：

性能：
服务拆分粒度：
管理、开发成本：
系统复杂度增加：

随着互联网技术也业务的发展，  更细粒度的拆分需求、技术选项的灵活性、敏捷开发和部署、更好的扩展性需求、
以及云原生（微服务架构更适合云原生的部署方式，能够更好的利用云的弹性和资源管理能力）、故障隔离性。

的需求， 衍生出微服务架构的概念。


哪里这里微服务架构的核心是什么呢？？

服务的拆分、。。  大拆小。 每个组件模块 可独立的单体应用。

1.4 微服务架构

微服务架构是SOA的进一步发展，它推崇将应用拆分成更细粒度的服务。并使用轻量级机制进行通信。
开发人员可以更加专注于业务逻辑的实现，同时提高了系统的可扩展性和可维护性。

1.4.1 与SOA架构区别

服务粒度、部署方式、通信协议、数据管理(数据库等)、治理和开发和部署方式等方面存在一些差异。

目标：SOA的主要目标是实现跨平台的、可重用的服务，以支持复杂的企业级应用。
微服务架构的主要目标是实现灵活、可扩展的系统，通过快速响应业务需求来支持业务创新。

总的来说，SOA架构和微服务架构在规模、粒度、数据管理、部署和扩展、耦合度、技术栈以及通信方式等方面存在明显的区别。这些区别使得它们适用于不同的场景和需求。在选择使用哪种架构时，需要根据具体的业务需求和技术环境进行综合考虑。

微服务架构是SOA的进一步发展，它推崇将应用拆分成更细粒度的服务。并使用轻量级机制进行通信。具体的区别在于几个方面: 规模和粒度、数据管理、部署和扩展、耦合度、技术栈。 ①规模和粒度方面(微服务的粒度更细，每个服务专注于一个明确定义的功能)，具体的拆分粒度需要结合实际业务场景。 ②数据管理方面：SOA通常使用中心化的数据存储和管理，多个服务可能会共享相同的数据源，而微服务中每个服务通常有自己的数据存储，与其他服务隔离，每个服务负责自己的数据管理。(这一段也有不足的地方：比如数据在多个系统的共享使用，需要通过服务，本来可以直接通过存储层获取的。更好的解决办法是，把数据层也作为服务，在微服务中共享和管理，提高共享能力，比如mt的cel)。 ③部署和扩展性方面：微服务架构允许每个微服务独立部署和扩展，可以更灵活地处理负载和维护。而SOA因为粒度的原因可能不是很灵活，小的改动可能影响的范围更大。④耦合度方面，SOA中服务之间的耦合度较高，因为它们可能共享数据模型和接口定义。⑤通信方式：SOA通常使用各种协议进行通信，如SOAP、REST等，微服务使用轻量级的协议，如HTTP/REST或gRPC等。微服务的目的主要是实现灵活、可扩展的系统，通过快速响应业务需求来支持业务创新。

1.5 后微服务时代

在微服务架构成熟之后，业界开始探索更加灵活的架构风格，如无服务器架构。
进一步简化了应用程序的开发和部署过程，使得开发人员可以更加专注于业务逻辑的实现，而无需关心底层的基础设施和资源管理。

2. 系统架构设计原则

系统架构设计原则？

我认为最核心的三个原则：合适、简单、演化这是架构设计的核心原则思想。另外的不同的架构模式也有一些其它的基本原则包括高可用、可扩展、可维护性、松耦合、性能优化、安全性、一致性。微服务架构、分布式系统架构设计、云原生应用开发。以前作为新手很多时候会听到你这不行

3. 微服务架构相关技术

3.1 服务拆分与设计

3.2 服务注册与发现

3.3 服务通信

3.4 服务稳定性

3.5 容器化技术

3.6 服务网格

3.7 CI/CD(持续集成)

4. 微服务架构详细介绍

对微服务架构的理解：微服务架构的目的是使得开发人员专注业务逻辑实现，无需关系底层的基础设施和资源管理。需要实现这一目标，要从以下几个方面展开：理解微服务架构的原理、熟悉微服务架构的内容(有哪些组成)、怎么做，怎么实现、最新的技术方案

4.1 微服务架构原理

架构原理是微服务架构的指导思想，目标是使得开发人员能够更加专注于业务功能的实现，而无需过多关注底层的技术细节和复杂性。
那从以下几个方面体现：

服务拆分：将一个大型的单体应用程序拆分成多个小型的服务。每个服务都是一个独立的、可独立部署和扩展的单元，具有明确的业务边界。这种拆分有助于减少系统的复杂性，提高系统的可维护性和可扩展性。
独立部署：每个微服务都可以独立地进行开发、测试和部署。快速迭代和交付新功能
去中心化：微服务架构强调服务的去中心化，即每个服务都是自治的，不依赖于中心化的管理或协调。系统更加灵活和可扩展。无状态，方便运维。
轻量级通信：微服务之间通过轻量级的通信机制进行交互，如HTTP/REST、gRPC等。这种通信机制使得服务之间的通信更加简单、高效和可靠。
服务自治：服务的注册、发现、负载均衡、容错处理等。这使得服务能够自我管理和自我恢复，提高了系统的稳定性和可用性。
技术异构性：微服务架构允许使用不同的技术栈和编程语言来开发不同的微服务。
高度可伸缩性：微服务架构可以根据需求对每个微服务进行独立的扩展。这允许系统根据业务压力和性能需求进行动态伸缩，以满足不断变化的业务需求。

4.2 微服务架构组成

服务治理
服务通信
服务注册与发现
独立部署与扩展
服务拆分
容器与弹性

4.3 下一代微服务架构(ServiceMesh)

服务通信：Service Mesh(服务网格) 。

以轻量级的网络代理的方式与应用程序部署在一起，用于保证服务与服务之间调用的可靠性，这与传统的微服务脚骨有着本质的区别。这么做的原因主要有：

跨语言服务调用的需要
云原生应用服务治理的需要

4.3.1 什么是Service Mesh

一种新型的用于处理服务与服务之间通信的技术，尤其适用于以云原生应用形式部署的服务。
可以说Service Mesh是微服务架构中的一个重要组成部分

Service Mesh是一个专用的基础设施层，用于处理微服务之间的通信。它通过在微服务之间插入一个轻量级的网络代理来提供诸如服务发现、负载均衡、故障恢复、安全性等功能。Service Mesh的主要目标是将这些通信相关的复杂性从应用程序代码中抽象出来，让开发人员可以更加专注于业务功能的实现。

Service Mesh之前：微服务之间的通信和管理主要依赖于一些传统的解决方案和工具。

通过直接的网络调用（如HTTP、RESTful API、gRPC等）实现的。每个微服务都需要处理与其他服务的通信细节，包括服务发现、负载均衡、故障恢复、安全性等。这导致微服务代码中包含了大量的网络通信逻辑，使得代码变得复杂且难以维护。（抽离出基础组件呢?）
为了解决这些问题，一些工具和框架被开发出来：服务注册与发现工具（如Eureka、Consul、ZooKeeper等）用于管理微服务实例的网络地址，并提供服务发现的功能。负载均衡器（如Nginx、HAProxy等）用于将客户端的请求分发到合适的服务实例上。此外，还有一些API网关（如Spring Cloud Gateway、Zuul等）用于处理跨服务的请求路由、安全认证、限流等。

然而：这些工具和框架仍然需要开发人员手动配置和管理，而且它们通常是与微服务代码紧密耦合的。这意味着每当微服务发生变化时，开发人员都需要相应地更新这些配置和管理逻辑。这增加了维护的复杂性，并降低了系统的可靠性和灵活性。

Service Mesh的出现解决了这些问题。它通过在微服务之间插入一个轻量级的网络代理来提供通信和管理功能。这些网络代理形成了一个独立的网络层，负责处理微服务之间的通信细节，如服务发现、负载均衡、故障恢复、安全性等。由于这些通信相关的逻辑被抽象出来，微服务代码可以更加专注于业务功能的实现。同时，Service Mesh提供了对微服务通信的可见性和控制，帮助开发人员更好地理解和管理微服务之间的交互。

因此，可以说Service Mesh是对传统微服务通信和管理方案的改进和扩展。它通过引入一个独立的网络层来简化微服务之间的通信，并提供更加灵活、可靠和安全的通信功能。

4.3.2 ServiceMesh的实现原理

SideCar
Control Plane

第一代Service Mesh的代表

Linkerd 基于Twiitter的Fingle，使用Scala编写，被誉为业界第一个Service Mesh项目，在长期的实际生产环境中获得验证，但由于很多功能被后续框架所取代，发展优先。

Envoy底层基于C++，性能上优于使用Scala的Linkerd，它在性能和资源消耗上表现得非常出色，被istio收编之后，专注于数据平面。

这2个开源实现都是以Sidecar为核心，绝大部分关注点都是如何做好Proxy，并完成一些通用控制面的功能。但是当你在容器中大量部署Sidecar以后，如何管理和控制这些Sidecar本身就是一个不小的挑战。

第二代Service Mesh主要改进集中在更强大的控制面功能，典型代表有Istio和Conduit

Service Mesh的出现是由微服务架构推动的，随着服务的拆分，服务治理面临巨大的挑战。

4.3.3 Service Mesh缺点

增加系统复杂性：在微服务架构中引入了一个额外的层，会增加系统的整体复杂性。开发人员需要了解并管理这个额外的层，这可能需要额外的培训和知识。
额外的资源开销：每个微服务实例都需要一个Sidecar代理，这可能会增加硬件和软件资源的开销。这些额外的资源需求可能会增加部署和运营成本。
运维复杂性：Service Mesh的引入可能会增加运维的复杂性。例如，需要管理和监控Sidecar代理的健康状态，以及确保它们与微服务实例之间的正确配置和交互。
版本管理和升级：由于Service Mesh是一个独立的组件，因此它有自己的版本和升级周期。这可能会与微服务的版本和升级周期产生冲突，需要额外的协调和规划。
安全问题：尽管Service Mesh提供了更高的安全性，但它也可能引入新的安全风险。例如，Sidecar代理可能成为攻击者的目标，因为它们负责处理微服务之间的通信。
调试和故障排查：由于Service Mesh将通信逻辑从应用程序代码中抽象出来，这可能会使调试和故障排查变得更加困难。开发人员可能需要查看多个组件的日志和状态，以确定问题的根本原因。
学习和掌握曲线：对于许多开发人员和运维团队来说，学习和掌握Service Mesh可能需要一些时间。这可能会影响项目的进度和效率。

问题与缺陷
Service-mesh有一定的价值， 但引入Service-mesh同时也会面临一些挑战，表现在以下两个方面
1. 一次调用多了进程间两跳通信（或流量劫持）， 势必对性能有较大影响，目前看吞吐量降低30%左右
2. 流程复杂度增加，需要更全面的稳定性建设，同时维护成本也会增加

4.3.4 ServiceMesh落地方案和效果

mt的落地方案和效果
bz的落地方案和效果

4.4 架构模式中重要组成

组件化
分层
通信机制
服务治理
可扩展性
安全性
监控和日志记录

4.5 微服务的拆分原则

单一职责、服务自治、服务可复用、服务粒度(照业务功能划分)、服务高内聚、低耦合原则、易于测试、服务可扩展原则。